約 2,839,551 件
https://w.atwiki.jp/usb_audio/pages/24.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 26 Offset Field Size Value Description 0 bLowScale 1 Number The setting for the attribute of the lowlevel Scaling Control. 1 bHighScale 1 Number The setting for the attribute of the highlevel Scaling Control. 2.4 Type III Formats These formats are based upon the IEC1937 standard. The IEC1937 standard describes a method to transfer non-PCM encoded audio bitstreams over an IEC958 digital audio interface, together with the transfer of the accompanying “Channel Status” and “User Data.” The IEC958 standard specifies a widely used method of interconnecting digital audio equipment with twochannel linear PCM audio. The IEC1937 standard describes a way in which the IEC958 interface shall be used to convey non-PCM encoded audio bit streams for consumer applications. The same basic techniques used in IEC1937 are reused here to convey non-PCM encoded audio bit streams over a Type III formatted audio stream. 2.4.1 Type III Format Type Descriptor The Type III Format Type is identical to the Type I PCM Format Type, set up for two-channel 16-bit PCM data. It therefore uses two audio subframes per audio frame. The subframe size is two bytes and the bit resolution is 16 bits. The Type III Format Type descriptor is identical to the Type I Format Type descriptor but with the bNrChannels field set to two, the bSubframeSize field set to two and the bBitResolution field set to 16. All the techniques used to correctly transport Type I PCM formatted streams over USB equally apply to Type III formatted streams. The non-PCM encoded audio bitstreams that are transferred within the basic 16-bit data area of the IEC1937 subframes (time-slots 12 [LSB] to 27 [MSB]) are placed unaltered in the two available 16-bit audio subframes per audio frame of the Type III formatted USB stream. The additional information in the IEC1937 subframes (channel status, user bits etc.) is discarded. Refer to the IEC1937 standard for a detailed description of the exact contents of the subframes. The layout of the Type III Format Type descriptor is given here for clarity. All preassigned fields have been filled in. Table 2-23 Type III Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 8+(ns*3) 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_III. Constant identifying the Format Type the AudioStreaming interface is using. 4 bNrChannels 1 Number Indicates the number of ‘virtual’ physical channels in the audio data stream. Must be set to two. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 27 Offset Field Size Value Description 5 bSubframeSize 1 Number The number of bytes occupied by one audio subframe. Must be set to 2. 6 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subframe. 7 bSamFreqType 1 Number Indicates how the sampling frequency can be programmed 0 Continuous sampling frequency1..255 The number of discrete sampling frequencies supported by the isochronous data endpoint of the AudioStreaming interface (ns) 8... See sampling frequency tables, below. Depending on the value in the bSamFreqType field, the layout of the next part of the descriptor is as shown in the following tables. Table 2-24 Continuous Sampling Frequency Offset Field Size Value Description 8 tLowerSamFreq 3 Number Lower bound in Hz of the sampling frequency range for this isochronous data endpoint. 11 tUpperSamFreq 3 Number Upper bound in Hz of the sampling frequency range for this isochronous data endpoint. Table 2-25 Discrete Number of Sampling Frequencies Offset Field Size Value Description 8 tSamFreq [1] 3 Number Sampling frequency 1 in Hz for this isochronous data endpoint. … … … … … 8+(ns-1)*3 tSamFreq [ns] 3 Number Sampling frequency ns in Hz for this isochronous data endpoint. Note In the case of adaptive isochronous data endpoints that support only a discrete number of sampling frequencies, the endpoint must at least tolerate ±1000 PPM inaccuracy on the reported sampling frequencies. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 28 3 Adding New Audio Data Formats Adding new Audio Data Formats to this specification is achieved by proposing a fully documented Audio Data Format to the Audio Device Class Working Group. Upon acceptance, they will register the new Audio Data Format (attribute a unique wFormatTag) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Audio Data Formats. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 29 Appendix A. Additional Audio Device Class Codes A.1 Audio Data Format Codes A.1.1 Audio Data Format Type I Codes Table A-1 Audio Data Format Type I Codes Name wFormatTag TYPE_I_UNDEFINED 0x0000 PCM 0x0001 PCM8 0x0002 IEEE_FLOAT 0x0003 ALAW 0x0004 MULAW 0x0005 A.1.2 Audio Data Format Type II Codes Table A-2 Audio Data Format Type II Codes Name wFormatTag TYPE_II_UNDEFINED 0x1000 MPEG 0x1001 AC-3 0x1002 A.1.3 Audio Data Format Type III Codes Table A-3 Audio Data Format Type III Codes Name wFormatTag TYPE_III_UNDEFINED 0x2000 IEC1937_AC-3 0x2001 IEC1937_MPEG-1_Layer1 0x2002 IEC1937_MPEG-1_Layer2/3 orIEC1937_MPEG-2_NOEXT 0x2003 IEC1937_MPEG-2_EXT 0x2004 IEC1937_MPEG-2_Layer1_LS 0x2005 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 30 Name wFormatTag IEC1937_MPEG-2_Layer2/3_LS 0x2006 A.2 Format Type Codes Table A-4 Format Type Codes Format Type Code Value FORMAT_TYPE_UNDEFINED 0x00 FORMAT_TYPE_I 0x01 FORMAT_TYPE_II 0x02 FORMAT_TYPE_II 0x03 A.3 Format-Specific Control Selectors A.3.1 MPEG Control Selectors Table A-5 MPEG Control Selectors Control Selector Value MPEG_CONTROL_UNDEFINED 0x00 MP_DUAL_CHANNEL_CONTROL 0x01 MP_SECOND_STEREO_CONTROL 0x02 MP_MULTILINGUAL_CONTROL 0x03 MP_DYN_RANGE_CONTROL 0x04 MP_SCALING_CONTROL 0x05 MP_HILO_SCALING_CONTROL 0x06 A.3.2 AC-3 Control Selectors Table A-6 AC-3 Control Selectors Control Selector Value AC_CONTROL_UNDEFINED 0x00 AC_MODE_CONTROL 0x01 AC_DYN_RANGE_CONTROL 0x02 AC_SCALING_CONTROL 0x03 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/gdiplus2/pages/26.html
1.使い方 2.バイナリ 3.readme 4.SS 5.履歴 使用にあたって 使い方 オプション一覧 使用にあたって 言うまでも無く、非常に危険な代物です。ソフトウェアの挙動を理解した上でご利用ください。CPUパワーを必要とするので、できるだけハイスペックなPCをお奨めします。 現在のところ、Windows 2000/XP で動作するハズですが、基本的にXPでのみ動作確認しています。使用は自己責任でお願いします。どんな損害がおこっても補償できません。 使い方 仕掛けたい実行ファイルをgdi++.exeにドラッグ ドロップすると、フックされた状態で起動します。Windows標準のコントロールのフォント描画にも影響が及びます。 オプション一覧 設定ファイル"gdi++.ini"を同じディレクトリに置くことで、レンダリングの設定ができます。（なくても動きます） [General] Quality=1 Weight=0 Enhance=0 UseSubPixel=0 SubPixelDirection=0 MaxHeight=0 ForceAntialiasedQuality=0 [Exclude] FixedSys Marlett メイリオ [Individual] Tahoma=3 [ExcludeModule] iexplore.exe firefox.exe Qualityフォントの品質を調節します。0 何もしない 1 2倍キレイ（デフォルト） 2 3倍キレイ 3 4倍キレイ Weightフォントの濃さを調節します。(n + 1)回重ねて描画します。 Enhance水平・垂直の輪郭線を強調します。0 強調しない(デフォルト) 1 少し強調 2 ふつうに強調 3 強く強調 4 激しく強調 UseSubPixel簡易サブピクセルレンダリング（ClearTypeもどき）を有効にします。0 つかわない（デフォルト） 1 つかう SubPixelDirectionサブピクセルレンダリングを使うときの、サブピクセルの並び順を指定します。ほとんどの液晶モニタは左からRGBの順にサブピクセルが並んでいますが、たまにBGRの順で並んでいるモニタもあるようです。0 RGB（デフォルト） 1 BGR MaxHeightスムージングを掛ける最大のフォントサイズを「ピクセル単位で」指定します。0 すべてのサイズ（デフォルト） ForceAntialiasedQualityWindowsのClearTypeを無視するかどうかを指定します。無視すれば描画が高速になります。0 標準の品質（デフォルト） 1 ClearTypeを無視 [Exclude]セクション標準のレンダラで描画したいフォントを一行に一書体ずつ記入します。フォント名がリストに合致すれば、gdi++.dll は標準のレンダラに描画を丸投げします。ビットマップフォントや、ClearType系のフォントにどうぞ。 [Individual]セクション指定したフォント毎にWeightを設定できます。 [ExcludeModule]セクションgdi++.dllを適用させたくない実行ファイルを指定できます。このセクションに記述された実行ファイルにはgdi++.dllが適用されません。
https://w.atwiki.jp/usb_audio/pages/22.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 11 Offset Field Size Value Description 8 tLowerSamFreq 3 Number Lower bound in Hz of the sampling frequency range for this isochronous data endpoint. 11 tUpperSamFreq 3 Number Upper bound in Hz of the sampling frequency range for this isochronous data endpoint. Table 2-3 Discrete Number of Sampling Frequencies Offset Field Size Value Description 8 tSamFreq [1] 3 Number Sampling frequency 1 in Hz for this isochronous data endpoint. … … … … … 8+(ns-1)*3 tSamFreq [ns] 3 Number Sampling frequency ns in Hz for this isochronous data endpoint. Note In the case of adaptive isochronous data endpoints that support only a discrete number of sampling frequencies, the endpoint must at least tolerate ±1000 PPM inaccuracy on the reported sampling frequencies. 2.2.6 Supported Formats The following paragraphs list all currently supported Type I Audio Data Formats. 2.2.6.1 PCM Format The PCM (Pulse Coded Modulation) format is the most commonly used audio format to represent audio data streams. The audio data is not compressed and uses a signed two’s-complement fixed point format. It is left-justified (the sign bit is the Msb) and data is padded with trailing zeros to fill the remaining unused bits of the subframe. The binary point is located to the right of the sign bit so that all values lie within the range [-1,+1). 2.2.6.2 PCM8 Format The PCM8 format is introduced to be compatible with the legacy 8-bit wave format. Audio data is uncompressed and uses 8 bits per sample (bBitResolution = 8). In this case, data is unsigned fixed-point, left-justified in the audio subframe, Msb first. The range is [0,255]. 2.2.6.3 IEEE_FLOAT Format The IEEE_FLOAT format is based on the ANSI/IEEE-754 floating-point standard. Audio data is represented using the basic single-precision format. The basic single-precision number is 32 bits wide and has an 8-bit exponent and a 24-bit mantissa. Both mantissa and exponent are signed numbers, but neither is represented in two s-complement format. The mantissa is stored in sign magnitude format and the exponent in biased form (also called excess-n form). In biased form, there is a positive integer (called the bias) which is subtracted from the stored number to get the actual number. For example, in an eight-bit exponent, the bias is 127. To represent 0, the number 127 is stored. To represent -100, 27 is stored. An USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 12 exponent of all zeroes and an exponent of all ones are both reserved for special cases, so in an eight-bit field, exponents of -126 to +127 are possible. In the basic floating-point format, the mantissa is assumed to be normalized so that the most significant bit is always one, and therefore is not stored. Only the fractional part is stored. The 32-bit IEEE-754 floating-point word is broken into three fields. The most significant bit stores the sign of the mantissa, the next group of 8 bits stores the exponent in biased form, and the remaining 23 bits store the magnitude of the fractional portion of the mantissa. For further information, refer to the ANSI/IEEE-754 standard. The data is conveyed over USB using 32 bits per sample (bBitResolution = 32; bSubframeSize = 4). 2.2.6.4 ALaw Format and mLaw Format Starting from 12- or 16-bits linear PCM samples, simple compression down to 8-bits per sample (one byte per sample) can be achieved by using logarithmic companding. The compressed audio data uses 8 bits per sample (bBitsPerSample = 8). Data is signed fixed point, left-justified in the subframe, Msb first. The compressed range is [-128,128]. The difference between Alaw and mLaw compression lies in the formulae used to achieve the compression. Refer to the ITU G.711 standard for further details. 2.3 Type II Formats Type II formats are used to transmit non-PCM encoded audio data into bitstreams that consist of a sequence of encoded audio frames. 2.3.1 Encoded Audio Frames An encoded audio frame is a sequence of bits that contains an encoded representation of one or more physical audio channels. The encoding takes place over a fixed number of audio samples. Each encoded audio frame contains enough information to entirely reconstruct the audio samples (albeit not lossless), encoded in the encoded audio frame. No information from adjacent encoded audio frames is needed during decoding. The number of samples used to construct one encoded audio frame depends on the encoding scheme. (For MPEG, the number of samples per encoded audio frame (nf) is 384 for Layer I or 1152 for Layer II. For AC-3, the number of samples is 1536.) In most cases, the encoded audio frame represents multiple physical audio channels. The number of bits per encoded audio frame may be variable. The content of the encoded audio frame is defined according to the implemented encoding scheme. Where applicable, the bit ordering shall be MSB first, relative to existing standards of serial transmission or storage of that encoding scheme. An encoded audio frame represents an interval longer than the USB frame time of 1 ms. This is typical of audio compression algorithms that use psycho-acoustic or vocal tract parametric models. Note It is important to make a clear distinction between an audio frame (see Section 2.2.3, “Audio Frame”) and an encoded audio frame. The overloaded use of the term audio frame could cause confusion. Therefore, this specification will always use the qualifier ‘encoded’ to refer to MPEG or AC-3 encoded audio frames. 2.3.2 Audio Bitstreams An encoded audio bitstream is a concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Subsequent encoded audio frames are independent and can be decoded separately. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 13 2.3.3 USB Packets Encoded audio bitstreams are packetized when transported over an isochronous pipe. Each USB packet contains only part of a single encoded audio frame. Packet sizes are determined according to the shortpacket protocol. The encoded audio frame is broken down into a number of packets, each containing wMaxPacketSize bytes except for the last packet, which may be smaller and contains the remainder of the encoded audio frame. If the MaxPacketsOnly bit D7 in the bmAttributes field of the class-specific endpoint descriptor is set, the last (short) packet must be padded with zero bytes to wMaxPacketSize length. No USB packet may contain bits belonging to different encoded audio frames. If the encoded audio frame length is not a multiple of 8 bits, the last byte in the last packet is padded with zero bits. The decoder must ignore all padded extra bits and bytes. Consecutive encoded audio frames are separated by at least one Transfer Delimiter. A Transfer Delimiter must be sent in all consecutive USB frames until the next encoded audio frame is due. The above rules guarantee that a new encoded audio frame always starts on a USB packet boundary. 2.3.4 Bandwidth Allocation The encoded audio frame time tf equals the number of audio samples per encoded audio frame nf divided by the sampling rate fs of the original audio samples. 数式 The allocated bandwidth for the pipe must accommodate for the largest possible encoded audio frame to be transmitted within an encoded audio frame time. This should take into account the Transfer Delimiter requirement and any differences between the time base of the stream and the USB frame timer. The device may choose to consume more bandwidth than necessary (by increasing the reported wMaxPacketSize) to minimize the time needed to transmit an entire encoded audio frame. This can be used to enable early decoding and therefore minimize system latency. 2.3.5 Timing The timing reference point is the beginning of an encoded audio frame. Therefore, the USB packet that contains the first bits (usually the encoded audio frame sync word) of the encoded audio frame is used as a timing reference in USB space. This USB packet is called the reference packet. The transmission of the reference packet of an encoded audio frame should begin at the target playback time of that frame (minus the endpoint’s reported delay) rounded to the nearest USB frame time. This guarantees that, at the receiving end, the arrival of subsequent reference packets matches the encoded audio frame time tf as closely as possible. 2.3.6 Type II Format Type Descriptor The Type II Format Type descriptor starts with the usual three fields bLength, bDescriptorType and bDescriptorSubtype. The bFormatType field indicates this is a Type II descriptor. The wMaxBitRate field contains the maximum number of bits per second this interface can handle. It is a measure for the buffer size available in the interface. The wSamplesPerFrame field contains the number of non-PCM encoded audio samples contained within a single encoded audio frame The sampling frequency capabilities of the endpoint are reported using the bSamFreqType field andfollowing fields. Table 2-4 Type II Format Type Descriptor Offset Field Size Value Description USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 14 Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 9+(ns*3) 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_II. Constant identifying the Format Type the AudioStreaming interface is using. 4 wMaxBitRate 2 Number Indicates the maximum number of bits per second this interface can handle. Expressed in kbits/s. 6 wSamplesPerFrame 2 Number Indicates the number of PCM audio samples contained in one encoded audio frame. 8 bSamFreqType 1 Number Indicates how the sampling frequency can be programmed 0 Continuous sampling frequency1..255 The number of discrete sampling frequencies supported by the isochronous data endpoint of the AudioStreaming interface (ns) 9... See sampling frequency tables, below. Depending on the value in the bSamFreqType field, the layout of the next part of the descriptor is as shown in the following tables. Table 2-5 Continuous Sampling Frequency Offset Field Size Value Description 9 tLowerSamFreq 3 Number Lower bound in Hz of the sampling frequency range for this isochronous data endpoint. 12 tUpperSamFreq 3 Number Upper bound in Hz of the sampling frequency range for this isochronous data endpoint. Table 2-6 Discrete Number of Sampling Frequencies Offset Field Size Value Description 9 tSamFreq [1] 3 Number Sampling frequency 1 in Hz for this isochronous data endpoint. … … … … … USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 15 Offset Field Size Value Description 9+(ns-1)*3 tSamFreq [ns] 3 Number Sampling frequency ns in Hz for this isochronous data endpoint. Note In the case of adaptive isochronous data endpoints that support only a discrete number of sampling frequencies, the endpoint must at least tolerate ±1000 PPM inaccuracy on the reported sampling frequencies. 2.3.7 Rate feedback If the isochronous data endpoint needs explicit rate feedback (adaptive source, asynchronous sink), the feedback pipe shall report the number of equivalent PCM audio samples. The host will accumulate this data and start transmission of an encoded audio frame whenever the current number of samples exceeds the number of samples per encoded audio frame. The remainder is kept in the accumulator. 2.3.8 Supported Formats The following sections list all currently supported Type II Audio Data Formats. Format-specific descriptors and format-specific requests are explained in more detail. 2.3.8.1 MPEG Format In the current specification, only MPEG decoding aspects are considered. Real-time MPEG encoding peripherals are not (yet) available and consequently are not covered by this specification. 2.3.8.1.1 MPEG Format-Specific Descriptor The wFormatTag field is a duplicate of the wFormatTag field in the class-specific AudioStreaming interface descriptor. The same field is used here to identify the format-specific descriptor. The bmMPEGCapabilities bitmap field describes the capabilities of the MPEG decoder built into the AudioStreaming interface. Some general information must be retrieved from the Format Type-specific descriptor. For instance, the sampling frequencies supported by the decoder are reported through the Format Type-specific descriptor. This includes the ability of the decoder to handle low sampling frequencies (16 kHz, 22.05 kHz and 24 kHz) besides the standard 32 kHz, 44.1 kHz and 48 kHz sampling frequencies. Bits D2..0 of the bmMPEGCapabilities field are used to indicate which layers this decoder is capable of processing. The different layers relate to the different algorithms that are used during encoding and decoding. Bit D3 indicates that the decoder can only process the MPEG-1 base stream. Therefore, only Left and Right channels will be output. Bit D4 indicates that the decoder can handle MPEG-2 streams that contain two independent stereo pairs instead of the normal 3/2 encoding scheme. This bit is only applicable for MPEG-2 decoders. Bit D5 indicates that the decoder supports the MPEG dual channel mode. In this case, the MPEG-1 base stream does not contain Left and Right channels of a stereo pair but instead contains two independent mono channels. One of these channels can be selected through the proper request (Dual Channel Control) and reproduced over the Left and Right output channels simultaneously. Bit D6 indicates that the decoder supports the DVD MPEG-2 augmentation to 7.1 channels instead of the standard 5.1 channels. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/62.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 11 2 Audio Data Formats Audio Data formats can be divided in two main groups • Simple Audio Data Formats • Extended Audio Data Formats Simple Audio Data Formats can then be subdivided into four groups according to type. The first group, Type I, deals with audio data streams that are transmitted over USB and are constructed on a sample-by-sample basis. Each audio sample is represented by a single independent symbol, contained in an audio subslot. Different compression schemes may be used to transform the audio samples into symbols. Note This is different from encoding. Compression is considered to take place on a per-audio-sample base. Each audio sample generates one symbol (e.g. A-law compression where a 16-bit audio sample is compressed into an 8 bit symbol). If multiple physical audio channels are formatted into a single audio channel cluster, then samples at time x of subsequent channels are first contained into audio subslots. These audio subslots are then interleaved, according to the cluster channel ordering as described in the main USB Audio Specification, and then grouped into an audio slot. The audio samples, taken at time x+1, are interleaved in the same fashion to generate the next audio slot and so on. The notion of physical channels is explicitly preserved during transmission. A typical example of Type I formats is the standard PCM audio data. The following figure illustrates the concept. ここに画像 Figure 2-1 Type I Audio Stream The second group, Type II, deals with those formats that do not preserve the notion of physical channels during the transmission over USB. Typically, all non-PCM encoded audio data streams belong to this group. A number of audio samples, often originating from multiple physical channels and taken over a certain period of time, are encoded into a number of bits in such a way that, after transmission, the original audio samples can be reconstructed to a certain degree of accuracy. The number of bits used for transmission is typically one or more orders of magnitude smaller than the number of bits needed to represent the original PCM audio samples, effectively realizing a considerable bandwidth reduction during transmission. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 12 ここに画像 Figure 2-2 Type II Audio Stream The third group, Type III, contains special formats that do not fit in both previous groups. In fact, they mix characteristics of Type I and Type II groups to transmit audio data streams over USB. One or more non-PCM encoded audio data streams are packed into “pseudo-stereo samples” and transmitted as if they were real stereo PCM audio samples. The sampling frequency of these pseudo samples matches the sampling frequency of the original PCM audio data streams. Therefore, clock recovery at the receiving end is easier than it is in the case of Type II formats. The drawback is that unless multiple non-PCM encoded streams are packed into one pseudo stereo stream, more bandwidth than necessary is consumed. The fourth group, Type IV, deals with audio streams that are not transmitted over USB. Instead, they interface with the audio function through an AudioStreaming interface that does not contain a USB isochronous IN or OUT endpoint. These streams typically connect via a digital interface like S/PDIF (or some other means of connectivity) but require interaction from the Host before they enter or leave the audio function. A typical example is an external S/PDIF connector that can accept an AC-3 encoded audio stream. This stream is first processed by an AC-3 decoder before the (decoded) logical audio channels enter the audio function through the Input Terminal that represents this S/PDIF connection. The capabilities of the AC-3 decoder are advertised by means of the AC-3 Decoder descriptor and the decoder Controls can be programmed through the AudioStreaming interface. In addition to the Simple Audio Data Formats described above, Extended Audio Data Formats are defined. These are based on the Simple Audio Data Formats Type I, II, and III definitions but they provide an optional packet header and for the Extended Audio Data Format Type I, an optional synchronous (i.e. sample accurate) control channel. Type IV Audio Data Formats do not have an Extended Audio Data Format definition. Section A.1, “Format Type Codes” summarizes the Audio Data Formats that are currently supported by the Audio Device Class. The following sections explain those formats in more detail. 2.1 Transfer Delimiter Isochronous data streams are continuous in nature, although the actual number of bytes sent per packet may vary throughout the lifetime of the stream (for rate adaptation purposes for instance). To indicate a temporary stop in the isochronous data stream without closing the pipe (and thus relinquishing the USB Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 13 bandwidth), an in-band Transfer Delimiter needs to be defined. This specification considers two situations to be a Transfer Delimiter. The first is a zero-length data packet and the second is the absence of an isochronous transfer in a USB (micro)frame that would normally have an isochronous transfer. Both situations are considered equivalent and the audio function is expected to behave the same. However, the second type consumes less isochronous USB bandwidth (i.e. zero bandwidth). In both cases, this specification considers a Transfer Delimiter to be an entity that can be sent over the USB. 2.2 Virtual Frame and Virtual Frame Packet Definitions To better describe packetization for audio the concept of a “virtual frame” (VF) is introduced. A virtual frame is defined as VF = (micro)frame * 2(bInterval-1) In addition, a “virtual frame packet” (VFP) is introduced. A virtual frame packet is defined as a packet that contains all the samples that are transferred over the bus during a virtual frame. For full-/high-speed endpoints, the virtual frame packets are exactly the same as the physical packets that are transferred over USB. However, for high-speed high-bandwidth endpoints, the virtual frame packet is the concatenation of the two or three physical packets that are transferred over the bus in a microframe. Note The USB Specification already considers the 2 or 3 transactions of a high-speed high-bandwidth transfer to be part of a single packet. See Section 5.12.3, “Clock Synchronization” The above definitions provide a model of ‘one (virtual frame) packet per (virtual) frame’, irrespective of the actual transactions on the USB. 2.3 Simple Audio Data Formats 2.3.1 Type I Formats The following sections describe the Audio Data Formats that belong to Type I. A number of terms and their definition are presented. 2.3.1.1 USB Packets Audio data streams that are inherently continuous must be packetized when sent over the USB. The quality of the packetizing algorithm directly influences the amount of effort needed to reconstruct a reliable sample clock at the receiving side. The goal must be to keep the instantaneous number of audio slots per virtual frame, ni as close as possible to the average number of audio slots per virtual frame, nav. The average nav must be calculated as follows ここに数式 where TVF is the duration of a virtual frame and Δt is the sample time (1/FS). In most cases nav will be a number with a fractional part. If the sampling rate is a constant, the allowable variation on ni is limited to one audio slot, that is, Δni = 1. This implies that all virtual frame packets must either contain INT(nav ) audio slots (small VFP) or INT(nav) + 1 (large VFP) audio slots. For all i ni = INT(nav) | INT(nav) + 1 Note In the case where nav = INT(nav), ni may vary between INT(nav) - 1 (small VFP), INT(nav) (medium VFP) and INT(nav) + 1 (large VFP). Furthermore, a large VFP must be generated as soon as it becomes available. Typically, a source will generate a number of small VFPs as long as the accumulated fractional part of nav remains 1. Once the Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 14 accumulated fractional part of nav becomes ≥ 1, the source must send a large VFP and decrement the accumulator by 1. Due to possible different notions of time in the source and the sink (they might each have their own independent sampling clock), the (small VFP)/(large VFP) pattern generated by the source may be different from what the sink expects. Therefore, the sink must be capable to accept a large VFP at all times. Example Assume FS = 44,100 Hz and TVF = 1ms. Then nav = 44.1 audio slots. Since the source can only send an integer number of audio slots per VF, it will send small VFPs of 44 audio slots. Each VF, it therefore sends ‘0.1 slot’ too few and it will accumulate this fractional part in an accumulator. After having sent 9 small VFPs of 44 audio slots, at the tenth VF it will have exactly one audio slot in excess and therefore can send a large VFP containing 45 audio slots. Decrementing the accumulator by 1 brings it back to 0 and the process can start all over again. The source will thus produce a repetitive pattern of 9 small VFPs of 44 audio slots followed by 1 large VFP of 45 audio slots. The following table illustrates the process Table 2-1 Packetization #VF nav ni Fraction Accumulator n 44.1 44 0.1 0.1 n+1 44.1 44 0.1 0.2 n+2 44.1 44 0.1 0.3 n+3 44.1 44 0.1 0.4 n+4 44.1 44 0.1 0.5 n+5 44.1 44 0.1 0.6 n+6 44.1 44 0.1 0.7 n+7 44.1 44 0.1 0.8 n+8 44.1 44 0.1 0.9 n+9 44.1 45 0.1 1.0 - 0 n+10 44.1 44 0.1 0.1 n+11 44.1 44 0.1 0.2 … … … … … *原文は枠線無し 2.3.1.2 Pitch Control If the sampling rate can be varied (to implement pitch control), the allowable variation on ni is limited to one audio slot per virtual frame. For all i ni+1 = ni | ni ± 1 Pitch control is restricted to adaptive endpoints only. AudioStreaming interfaces that support pitch control on their isochronous endpoint are required to report this in the class-specific endpoint descriptor. In addition, a Set/Get Pitch Control request is required to enable or disable the pitch control functionality. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 15 2.3.1.3 Audio Subslot The basic structure used to represent audio data is the audio subslot. An audio subslot holds a single audio sample. An audio subslot always contains an integer number of bytes. This specification limits the possible audio subslot sizes (bSubslotSize) to 1, 2, 3 or 4 bytes per audio subslot. An audio sample is represented using a number of bits (bBitResolution) less than or equal to the total number of bits available in the audio subslot, i.e. bBitResolution ≤ bSubslotSize*8. AudioStreaming endpoints must be constructed in such a way that a valid transfer can take place as long as the reported audio subslot size (bSubslotSize) is respected during transmission. If the reported bits per sample (bBitResolution) do not correspond with the number of significant bits actually used during transfer, the device will either discard trailing significant bits ([actual_bits_per_sample] bBitResolution) or interpret trailing zeros as significant bits ([actual_bits_per_sample] bBitResolution). 2.3.1.4 Audio Slot An audio slot consists of a collection of audio subslots, each containing an audio sample of a different physical audio channel, taken at the same moment in time. The number of audio subslots in an audio slot equals the number of logical audio channels in the audio channel cluster. The ordering of the audio subslots in the audio slot obeys the rules set forth in the USB Audio Specification. All audio subslots must have the same audio subslot size. 2.3.1.5 Audio Streams An audio stream is a concatenation of a potentially very large number of audio slots, ordered according to ascending time. Streams are packetized when transported over USB whereby virtual frame packets can only contain an integer number of audio slots. Each packet always starts with the same channel, and the channel order is respected throughout the entire transmission. If, for any reason, there are no audio slots available to construct a VFP, a Transfer Delimiter must be sent instead. 2.3.1.6 Type I Format Type Descriptor The Type I format type descriptor starts with the usual three fields bLength, bDescriptorType, and bDescriptorSubtype. The bFormatType field indicates this is a Type I descriptor. The bSubslotSize field indicates how many bytes are used to transport an audio subslot. The bBitResolution field indicates how many bits of the total number of available bits in the audio subslot are truly used by the audio function to convey audio information. Table 2-2 Type I Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 6 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_I. Constant identifying the Format Type the AudioStreaming interface is using. 4 bSubslotSize 1 Number The number of bytes occupied by one audio subslot. Can be 1, 2, 3 or 4. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/61.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 6 Table of Contents Scope of This Release.............................................................................................................2 Contributors............................................................................................................................2 Revision History.......................................................................................................................2 Table of Contents.....................................................................................................................6 List of Tables...........................................................................................................................7 List of Figures.........................................................................................................................8 List of Figures.........................................................................................................................8 1 Introduction......................................................................................................................9 1.1 Related Documents.....................................................................................................9 1.2 Terms and Abbreviations.............................................................................................9 2 Audio Data Formats........................................................................................................11 2.1 Transfer Delimiter......................................................................................................12 2.2 Virtual Frame and Virtual Frame Packet Definitions.................................................13 2.3 Simple Audio Data Formats.......................................................................................13 2.3.1 Type I Formats...................................................................................................13 2.3.2 Type II Formats..................................................................................................17 2.3.3 Type III Formats.................................................................................................19 2.3.4 Type IV Formats.................................................................................................20 2.4 Extended Audio Data Formats..................................................................................21 2.4.1 Extended Type I Formats...................................................................................21 2.4.2 Extended Type II Formats..................................................................................23 2.4.3 Extended Type III Formats.................................................................................24 2.4.4 Side Band Protocols...........................................................................................25 3 Adding New Audio Data Formats..................................................................................27 4 Adding New Side Band Protocols.................................................................................28 Appendix A. Additional Audio Device Class Codes....................................................29 A.1 Format Type Codes...................................................................................................29 A.2 Audio Data Format Bit Allocation in the bmFormats field..........................................29 A.2.1 Audio Data Format Type I Bit Allocations..........................................................29 A.2.2 Audio Data Format Type II Bit Allocations.........................................................29 A.2.3 Audio Data Format Type III Bit Allocations........................................................30 A.2.4 Audio Data Format Type IV Bit Allocations........................................................30 A.3 Side Band Protocol Codes........................................................................................31 Release 2.0 May 31, 2006 6 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 7 List of Tables Table 2-1 Packetization........................................................................................................14 Table 2-2 Type I Format Type Descriptor...........................................................................15 Table 2-3 Type II Format Type Descriptor..........................................................................18 Table 2-4 Type III Format Type Descriptor.........................................................................20 Table 2-5 Type IV Format Type Descriptor.........................................................................21 Table 2-6 Extended Type I Format Type Descriptor..........................................................22 Table 2-7 Extended Type II Format Type Descriptor.........................................................23 Table 2-8 Extended Type III Format Type Descriptor........................................................25 Table 2-9 Hi-Res Presentation TimeStamp Layout............................................................25 Table A-1 Format Type Codes.............................................................................................29 Table A-2 Audio Data Format Type I Bit Allocations.........................................................29 Table A-3 Audio Data Format Type II Bit Allocations........................................................29 Table A-4 Audio Data Format Type III Bit Allocations.......................................................30 Table A-5 Audio Data Format Type IV Bit Allocations......................................................30 Table A-6 Side Band Protocol Codes.................................................................................31 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 8 List of Figures Figure 2-1 Type I Audio Stream...........................................................................................11 Figure 2-2 Type II Audio Stream..........................................................................................12 Figure 2-3 Extended Type I Format.....................................................................................22 Figure 2-4 Extended Type II Format....................................................................................23 Figure 2-5 Extended Type III Format...................................................................................24 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 9 1 Introduction The intention of this document is to describe in detail all the Audio Data Formats that are supported by the Audio Device Class. This document is considered an integral part of the Audio Device Class Specification, although subsequent revisions of this document are independent of the revision evolution of the main USB Audio Specification. This is to easily accommodate the addition of new Audio Data Formats without impeding the core USB Audio Specification. 1.1 Related Documents • Universal Serial Bus Specification, Revision 2.0 (referred to in this document as the USB Specification). In particular, see Chapter 5, “USB Data Flow Model” and Chapter 9, “USB Device Framework.” • Universal Serial Bus Device Class Definition for Audio Devices (referred to in this document as USB Audio Device Class). • Universal Serial Bus Device Class Definition for Terminal Types (referred to in this document as USB Audio Terminal Types). • ANSI S1.11-1986 standard. • MPEG-1 standard ISO/IEC 111172-3 1993. (available from http //www.iso.ch ) • MPEG-2 standard ISO/IEC 13818-3 Feb. 20, 1997. (available from http //www.iso.ch ) • Digital Audio Compression Standard (AC-3), ATSC A/52A Aug. 20, 2001. (available from http //www.atsc.org ) • Windows Media Audio (WMA) specification. (available from http //www.microsoft.com) • ANSI/IEEE-754 floating-point standard. • ISO/IEC 60958 International Standard Digital Audio Interface and Annexes. • ISO/IEC 61937 standard. • ITU G.711 standard. • ETSI Specification TS 102 114, “DTS Coherent Acoustics; Core and Extensions”. (Available from http //webapp.etsi.org/action%5CPU/20020827/ts_102114v010101p.pdf) 1.2 Terms and Abbreviations This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial Bus, see Chapter 2, “Terms and Abbreviations,” in the USB Specification. AC-3 Audio compression standard from Dolby Labs. Audio Slot A collection of audio subslots, each containing a PCM audio sample of a different physical audio channel, taken at the same moment in time. Audio Stream A concatenation of a potentially very large number of audio slots ordered according to ascending time. Audio Subslot Holds a single PCM audio sample. DTS Acronym for Digital Theater Systems. DVD Acronym for Digital Versatile Disc. Encoded Audio Bit Stream A concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Encoded Audio Frame A sequence of bits that contains an encoded representation of audio samples from one or more physical audio channels taken over a fixed period of time. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 10 MPEG Acronym for Moving Pictures Expert Group. PCM Acronym for Pulse Coded Modulation. Virtual Frame A grouping of USB (micro)frames that are related. Virtual Frame Packet A packet that contains all the audio slots that are transferred over the bus during a virtual frame. Transfer Delimiter A unique token that indicates an interruption in an isochronous data packet stream. Can be either a zero-length data packet or the absence of an isochronous transfer in a certain USB frame. WMA Acronym for Windows Media Audio. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/19.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) USB Device Class Definition for Audio Devices Release 2.0 Release 2.0 May 31, 2006 May 31, 2006 1 Universal Serial Bus Device Class Definition for Audio Devices USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 2 Scope of This Release This document is the Release 2.0 of this device class definition. Contributors Geert Knapen (Editor) Philips Applied Technologies AppTech-USA 1101 McKay Drive M/S 16 San Jose, CA 95131 USA Phone +1 (408) 474-8774 E-mail geert.knapen(at)philips.com Mike Kent Roland Corporation Kaoru Ishimine Roland Corporation Shoichi Kojima Roland Corporation Robert Gilsdorf Creative Labs Daniel (D.J.) Sisolak Microsoft Corporation Jack Unverferth Microsoft Corporation Niel Warren Apple Computer, Inc. Len Layton C-Media Electronics Mark Cookson M-Audio Revision History Revision Date Filename Author Description 1.7 Sep. 3, 02 Audio17.doc USB-IF DWG Initial version. Based on Audio10.doc. This version will be used to capture the areas where the spec needs adjustments. Areas are indicated by comments. 1.7a Oct. 24, 02 Audio17a.doc Geert Knapen Areas are identified where changes need to be made. Some minor changes already introduced. 1.7b Oct. 24, 02 Audio17b.doc Geert Knapen Intermediate version 1.7c Dec. 10, 02 Audio17c.doc Geert Knapen Discussions from 12-18-2002 f2f meeting captured. Additional comments added. 1.7d Feb. 3, 03 Audio17d.doc Geert Knapen Changes from 1.7c accepted. Additional changes introduced. 1.7e Feb. 19, 03 Audio17e.doc Geert Knapen Introduced physical vs. logical channel cluster 1.7f Feb. 19, 03 Audio17f.doc Geert Knapen Accepted all changes in 1.7e. Fixed some typos. 1.7g Jun. 2, 03 Audio17g.doc Geert Knapen Major overhaul with the introduction of the RANGE attribute. 1.7h Jun. 3, 03 Audio17h.doc Geert Knapen Accepted all changes USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 3 Revision Date Filename Author Description 1.7i Jul. 10, 03 Audio17i.doc Geert Knapen Introduced clock domain, interface association descriptor 1.7j Jul. 10, 03 Audio17j.doc Geert Knapen Accepted all changes 1.7k Sep. 8, 03 Audio17k.doc Geert Knapen Introduced Function Subclass codes, extended interrupt usage, cleaned up clock domains and removed clock domain group concept. Replaced by Clock Source Entity. 1.7l Sep. 10, 03 Audio17l.doc Geert Knapen Accepted all the changes 1.7m Sep. 15, 03 Audio17m.doc Geert Knapen Cleaned up Interrupt description 1.7n Sep. 30, 03 Audio17n.doc Geert Knapen Accepted all changes 1.7o Sep. 30, 03 Audio17o.doc Geert Knapen Major rewrite w.r.t. Controls. 1.7p Nov. 05, 03 Audio17p.doc Geert Knapen Accepted all the changes. Added bit pairs for indicating Control availability 1.7q Nov. 07, 03 Audio17q.doc Geert Knapen Introduced the new concept of controlling sampling frequency 1.7r Dec. 01, 03 Audio17r.doc Geert Knapen Accepted all the changes 1.7s Dec. 10, 03 Audio17s.doc Geert Knapen Changed physical-logical cluster mapping. Added explanation on binding between physical buttons and Audio Controls 1.7t Feb. 04, 04 Audio17t.doc Geert Knapen Accepted all changes 1.7u Feb. 05, 04 Audio17u.doc Geert Knapen Introduced Effect Unit. Regrouped some PUs into the EU concept. Added Parametric EQ as an EU. Accepted all changes 1.7v Mar. 30, 04 Audio17v.doc Geert Knapen Full proof-read. Changed formatting and wording throughout the document 1.7w Mar. 30, 04 Audio17w.doc Geert Knapen Accepted all the changes. Added new Function Categories. Added physical cluster desctriptor to AS interface descriptor. 1.7x Apr. 13, 04 Audio17x.doc Geert Knapen Accepted all the changes. Added new Function Categories. Added support for encoders and decoders. 1.7y Apr. 28, 04 Audio17y.doc Geert Knapen Accepted all the changes. 1.7z May 15, 04 Audio17z.doc Geert Knapen Added some fields to encoder descriptors. 1.8 May 26, 04 Audio18.doc Geert Knapen Accepted all changes and promoted to 1.8 level USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 4 Revision Date Filename Author Description 1.8a Sep. 15, 04 Audio18a.doc Geert Knapen Corrected some errors in table offsets etc as indicated by Len Layton (CMedia) Identified the need to address ASR converter Unit 1.8b Mar. 15, 05 Audio18b.doc Geert Knapen Minor editorial changes 1.8c Aug. 10, 05 Audio18c.doc Geert Knapen Minor editorial changes 1.8d Aug. 16, 05 Audio18d.doc Geert Knapen Accepted editorial changes, based on F2F meeting review. Added and accepted an ID field for all encoder and decoder descriptors. This ID must also be passed into the requests that address the encoder or decoder. 1.8e Aug. 17, 05 Audio18e.doc Geert Knapen Redid the encoder sections. Added generic latency support. Added SRC Unit. 1.8f Aug. 31, 05 Audio18f.doc Geert Knapen Fixed some heading levels. Added DTS. 1.8g Sep. 02, 05 Audio18g.doc Geert Knapen Added Encoder and Decoder Error Codes. Accepted all the changes. 1.9RC1 Sep. 02, 05 Audio19RC1.doc Geert Knapen Republished unchanged as 1.9RC1. 1.9RC2 Oct. 05, 05 Audio19RC2.doc Geert Knapen Made several small editorial changes. Accepted all the changes. 1.9 Oct. 07, 05 Audio19.doc Geert Knapen Promoted to 1.9 without change. 2.0RC1 May 19, 06 Audio20RC1.doc Geert Knapen Addressed and accepted some minor changes. Declared this document as the Release Candidate for the 2.0 version. 2.0 May 31, 06 Audio20.doc Geert Knapen Added new Intellectual Property Disclaimer. Final version. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 5 Copyright © 1997-2006 USB Implementers Forum, Inc. All rights reserved. INTELLECTUAL PROPERTY DISCLAIMER A LICENSE IS HEREBY GRANTED TO REPRODUCE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED OR INTENDED HEREBY. USB-IF AND THE AUTHORS OF THIS SPECIFICATION EXPRESSLY DISCLAIM ALL LIABILITY FOR INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. USB-IF AND THE AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE THE INTELLECTUAL PROPERTY RIGHTS OF OTHERS. THIS SPECIFICATION IS PROVIDED “AS IS” AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE. ALL WARRANTIES ARE EXPRESSLY DISCLAIMED. USB-IF, ITS MEMBERS AND THE AUTHORS OF THIS SPECIFICATION PROVIDE NO WARRANTY OF MERCHANTABILITY, NO WARRANTY OF NON-INFRINGEMENT, NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE, AND NO WARRANTY ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. IN NO EVENT WILL USB-IF, MEMBERS OR THE AUTHORS BE LIABLE TO ANOTHER FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THE USE OF THIS SPECIFICATION, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. NOTE VARIOUS USB-IF MEMBERS PARTICIPATED IN THE DRAFTING OF THIS SPECIFICATION. CERTAIN OF THESE MEMBERS MAY HAVE DECLINED TO ENTER INTO A SPECIFIC AGREEMENT LICENSING INTELLECTUAL PROPERTY RIGHTS THAT MAY BE INFRINGED IN THE IMPLEMENTATION OF THIS SPECIFICATION. PERSONS IMPLEMENT THIS SPECIFICATION AT THEIR OWN RISK. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to audio-chair(at)usb.org 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 - 131 - 136 - 141 ここを編集
https://w.atwiki.jp/usb_audio/pages/65.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 26 Offset Field Size Value Description 4 qNanoSeconds 8 Number Offset in nanoseconds from the beginning of the audio stream. Note Timing information is intrinsically provided by the isochronous data transport mechanism itself (packets are synchronized to the USB SOF and the number of samples per packet is an overall measure of the audio data sampling rate). However, the high resolution presentation timestamp could potentially be used to deliver more accurate instantaneous timing information to the sink or to report a (constant) delay between the moment of transport over the USB and the moment of actual rendition. Care must be taken to ensure that the information contained in the Packet Header is at all times in agreement with the implicit timing information, delivered by the isochronous streaming mechanism. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 27 3 Adding New Audio Data Formats Adding new Audio Data Formats to this specification is achieved by proposing a fully documented Audio Data Format to the Audio Device Class Working Group. Upon acceptance, they will register the new Audio Data Format (attribute a unique bit position in the bmFormats field of the class-specific AS interface descriptor) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Audio Data Formats. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 28 4 Adding New Side Band Protocols Adding new Side Band Protocols to this specification is achieved by proposing a fully documented Side Band Protocol to the Audio Device Class Working Group. Upon acceptance, they will register the new Side Band Protocol (attribute a unique SideBandProtocol constant) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Side Band Protocols. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 29 Appendix A. Additional Audio Device Class Codes A.1 Format Type Codes Table A-1 Format Type Codes Format Type Code Value FORMAT_TYPE_UNDEFINED 0x00 FORMAT_TYPE_I 0x01 FORMAT_TYPE_II 0x02 FORMAT_TYPE_III 0x03 FORMAT_TYPE_IV 0x04 EXT_FORMAT_TYPE_I 0x81 EXT_FORMAT_TYPE_II 0x82 EXT_FORMAT_TYPE_III 0x83 A.2 Audio Data Format Bit Allocation in the bmFormats field A.2.1 Audio Data Format Type I Bit Allocations Table A-2 Audio Data Format Type I Bit Allocations Name bmFormats PCM D0 PCM8 D1 IEEE_FLOAT D2 ALAW D3 MULAW D4 Reserved. Must be set to 0. D30..D5 TYPE_I_RAW_DATA D31 A.2.2 Audio Data Format Type II Bit Allocations Table A-3 Audio Data Format Type II Bit Allocations Name bmFormats MPEG D0 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 30 Name bmFormats AC-3 D1 WMA D2 DTS D3 Reserved. Must be set to 0. D30..D4 TYPE_II_RAW_DATA D31 A.2.3 Audio Data Format Type III Bit Allocations Table A-4 Audio Data Format Type III Bit Allocations Name bmFormats IEC61937_AC-3 D0 IEC61937_MPEG-1_Layer1 D1 IEC61937_MPEG-1_Layer2/3 or IEC61937_MPEG-2_NOEXT D2 IEC61937_MPEG-2_EXT D3 IEC61937_MPEG-2_AAC_ADTS D4 IEC61937_MPEG-2_Layer1_LS D5 IEC61937_MPEG-2_Layer2/3_LS D6 IEC61937_DTS-I D7 IEC61937_DTS-II D8 IEC61937_DTS-III D9 IEC61937_ATRAC D10 IEC61937_ATRAC2/3 D11 TYPE_III_WMA D12 Reserved. Must be set to 0. D31..D13 A.2.4 Audio Data Format Type IV Bit Allocations Table A-5 Audio Data Format Type IV Bit Allocations Name bmFormats PCM D0 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/16.html
原文：Audio Device Class Spec for Basic Audio Devices and Adopters Agreement(ZIP) このPDFだけロックがかかっててテキストが抽出できないのだがどうしたものか。まあ後回しだな。
https://w.atwiki.jp/usb_audio/pages/14.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 i Universal Serial Bus Device Class Definition for Audio Devices Release 1.0 March 18, 1998 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 ii Scope of This Release This document is the 1.0 release of this device class definition. Contributors Gal AshourIBM Corporation Billy BrackenridgeMicrosoft Corporation Oren TiroshAltec Lansing Craig ToddDolby Laboratories Remy ZimmermannLogitech Geert KnapenPhilips ITCL Interleuvenlaan 74-76 B-3001 Leuven-Heverlee BELGIUM Phone +32 16 390 734 Fax +32 16 390 600 E-mail Geert.Knapen(at)innet.be Revision History Revision Date Filename Author Description 0.1 Aug. 7, 95 Audio01.doc Geert Knapen Initial version. 0.2 Aug. 28, 95 Audio01.doc Geert Knapen Corrected typos.Attributes field from 8 to 16 bits.Auxiliary channel definition.Important issues added. 0.3 Oct. 9, 95 Audio03.doc Geert Knapen Intermediate version. 0.4 Nov. 29, 95 Audio04.doc Geert Knapen Change to Audio Function and Interface Property requests.Synch issues updated.Subclass divisions changed. 0.6 Dec. 19, 95 Audio06.doc Geert Knapen Listed remarks from last f2f Dec 7-8. 0.8 Dec. 12, 95 Audio08.doc Geert Knapen Incorporated changes, discussed at f2f Dec 6 95. 0.8a Jan. 20, 96 Audio08a.doc Geert Knapen Incorporated changes discussed at f2f Jan 18 95.Feedforward/feedback endpoint is now called synch endpoint. Feb. 5, 96 usb_au8a.doc Edited version of Audio08a.doc. 0.8b June. 5, 96 Audio08b.doc Geert Knapen Introduced new mixer concepts etc. 0.8c Oct. 1, 96 Audio08c.doc Geert Knapen Added appropriate descriptors and requests. 0.8d Dec. 1, 96 Audio08d.doc Geert Knapen Included remarks on 0.8c USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iii Revision Date Filename Author Description 0.8e Jan. 1, 97 Audio08e.doc Geert Knapen Included remarks on 0.8d. Added Dolby Prologic and Up/Down-mix Processing Units. 0.8f Mar. 1, 97 Audio08f.doc Geert Knapen Removed associated interface. Added Set/Get Memory requests for all Entities. Introduced copyright protection, Audio Interface Collections. Added Stereo Widening Processing Unit. Added Reverb Processing Unit. Added Chorus Unit. Added Bass Boost and Loudness Controls. 0.9rc Apr. 1, 97 Audio09rc.doc Geert Knapen Changed Section 5 structure. Removed many request codes. Added requests for Reverb and Chorus. Changed Terminal request structure. Included all remarks from last meeting. 0.9 May 1, 97 Audio09.doc Geert Knapen Added wLockDelay and bLockUnits fields to CS endpoint descriptor. Added bit to CS endpoint descriptor to indicate packet size restrictions. Revised endpoint descriptors according to new CCS layout. Added Dynamic Range Compressor PU. 0.9CE Sep 1, 97 Audio09CE.doc Geert Knapen Copy-edited for publication on the web. 0.9a Oct 1, 97 Audio09a.doc Geert Knapen Incorporated RRs 1.0RC Mar 1, 98 Audio10RC.doc Geert Knapen Added examples and cleaned up the formatting. 1.0 Mar 18, 98 Audio10.doc Geert Knapen Changed all references to 1.0. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iv Copyright © 1997, USB Implementers ForumAll rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. A LICENSE IS HEREBY GRANTED TO REPRODUCE AND DISTRIBUTE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY OTHER INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to techsup(atusb.org) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 v Table of Contents Scope of This Release.........................................................................................................ii Contributors........................................................................................................................ii Revision History ..................................................................................................................ii Table of Contents ................................................................................................................v List of Tables ....................................................................................................................viii List of Figures...................................................................................................................xiii 1 Introduction ................................................................................................................14 1.1 Scope....................................................................................................................14 1.2 Purpose .................................................................................................................14 1.3 Related Documents ...............................................................................................14 1.4 Terms and Abbreviations.......................................................................................14 2 Management Overview...............................................................................................17 3 Functional Characteristics.........................................................................................18 3.1 Audio Interface Class.............................................................................................18 3.2 Audio Interface Subclass and Protocol...................................................................18 3.3 Audio Synchronization Types.................................................................................19 3.3.1 Asynchronous .................................................................................................19 3.3.2 Synchronous...................................................................................................19 3.3.3 Adaptive .........................................................................................................19 3.4 Inter Channel Synchronization ...............................................................................19 3.5 Audio Function Topology .......................................................................................20 3.5.1 Input Terminal ................................................................................................21 3.5.2 Output Terminal..............................................................................................21 3.5.3 Mixer Unit .......................................................................................................22 3.5.4 Selector Unit...................................................................................................22 3.5.5 Feature Unit....................................................................................................23 3.5.6 Processing Unit...............................................................................................23 3.5.7 Extension Unit ................................................................................................28 3.5.8 Associated Interfaces......................................................................................28 3.6 Copy Protection .....................................................................................................28 3.7 Operational Model .................................................................................................29 3.7.1 AudioControl Interface ....................................................................................30 3.7.2 AudioStreaming Interface ...............................................................................31 4 Descriptors .................................................................................................................36 4.1 Device Descriptor ..................................................................................................36 4.2 Configuration Descriptor ........................................................................................36 4.3 AudioControl Interface Descriptors.........................................................................36 4.3.1 Standard AC Interface Descriptor....................................................................36 4.3.2 Class-Specific AC Interface Descriptor ...........................................................37 4.4 AudioControl Endpoint Descriptors ........................................................................57 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集
https://w.atwiki.jp/usb_audio/pages/64.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 21 Setting and encoded data streams (IEC61937) in another Alternate Setting of the interface. Note however that the external connection could also be vendor specific (like a parallel data interface). 2.3.4.1 Type IV Format Type Descriptor The bFormatType field indicates this is a Type IV descriptor. Table 2-5 Type IV Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 4 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_IV. Constant identifying the Format Type the AudioStreaming interface is using. 2.3.4.2 Type IV Supported Formats This specification supports all Audio Data Formats on an external connection that are defined on a USB pipe (Type I, II, and III). See Section 2.3.1.7, “Type I Supported Formats”, Section 2.3.2.8, “Type II Supported Formats”, and Section 2.3.3.2, “Type III Supported Formats”. The bit allocations in the bmFormats field of the class-specific AS interface descriptor for the different Type IV Audio Data Formats can be found in Appendix A.2.4, “Audio Data Format Type IV Bit Allocations.” 2.4 Extended Audio Data Formats Extended Audio Data Formats add support for a Packet Header to the previously defined Simple Audio Data Formats Type I, II, and III. For the Extended Audio Data Format Type I, an additional optional synchronous Control Channel is defined. 2.4.1 Extended Type I Formats Extended Audio Data Format Type I adds support for both a Packet Header and a synchronous Control Channel to the Simple Type I Format definition. All three elements (Packet Header, audio data, and Control Channel) of an Extended Type I packet are optional. The Extended Format Type I descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Control Channel, without Packet Header or audio data. The following figure further illustrates the concept. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 22 ここに画像 Figure 2-3 Extended Type I Format Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by a number of Extended Audio Slots. An Extended Audio Slot is the concatenation of a Control Word, followed by the Type I Audio Slot. The Control Channel therefore consists of a stream of Control Words, where each Control Word is synchronous to its associated Audio Slot. There are as many Control Channel Words per VFP as there are Audio Slots in the VFP. The byte size of the Control Words is independent of the Audio Subslot size and is the same for each Audio Slot. 2.4.1.1 Extended Type I Format Type Descriptor The first part of the Extended Type I Format Type descriptor is identical to the Simple Type I Format Type descriptor (See Section 2.3.1.6, “Type I Format Type Descriptor”.) Three additional fields are added to describe the Packet Header and the Control Channel. The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bControlSize field indicates the size in bytes of each Control Channel Word in the stream. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header and Control Channel. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”). If the Packet Header is not used, then the bHeaderLength field must be set to 0. Likewise, if the Control Channel is not implemented, then the bControlSize field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0. Table 2-6 Extended Type I Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 9 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant EXT_FORMAT_TYPE_I. Constant identifying the Format Type the AudioStreaming interface is using. 4 bSubslotSize 1 Number The number of bytes occupied by one audio subslot. Can be 1, 2, 3 or 4. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 23 Offset Field Size Value Description 5 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subslot. 6 bHeaderLength 1 Number Size of the Packet Header, in bytes. 7 bControlSize 1 Number Size of the Control Channel Words, in bytes. 8 bSideBandProtocol 1 Constant Constant, identifying the Side Band Protocol used for the Packet Header and Control Channel content. 2.4.2 Extended Type II Formats Extended Audio Data Format Type II adds support for a Packet Header to the Simple Type II Format definition. The elements (Packet Header and audio data) of an Extended Type II packet are optional. The Extended Format Type II descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Packet Header without audio data. The following figure further illustrates the concept. ここに画像 Figure 2-4 Extended Type II Format Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by the actual encoded audio frame data. 2.4.2.1 Extended Type II Format Type Descriptor The first part of the Extended Type II Format Type descriptor is identical to the Simple Type II Format Type descriptor (See Section 2.3.2.6, “Type II Format Type Descriptor”.) Two additional fields are added to describe the Packet Header. The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”). If the Packet Header is not used, then the bHeaderLength field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0. Table 2-7 Extended Type II Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 10 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 24 Offset Field Size Value Description 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant Ext_FORMAT_TYPE_II. Constant identifying the Format Type the AudioStreaming interface is using. 4 wMaxBitRate 2 Number Indicates the maximum number of bits per second this interface can handle. Expressed in kbits/s. 6 wSamplesPerFrame 2 Number Indicates the number of PCM audio samples contained in one encoded audio frame. 8 bHeaderLength 1 Number Size of the Packet Header, in bytes. 9 bSideBandProtocol 1 Constant Constant, identifying the Side Band Protocol used for the Packet Header content. 2.4.3 Extended Type III Formats Extended Audio Data Format Type III adds support for a Packet Header to the Simple Type III Format definition. The elements (Packet Header and audio data) of an Extended Type III packet are optional. The Extended Format Type III descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Packet Header without audio data. The following figure further illustrates the concept. ここに画像 Figure 2-5 Extended Type III Format Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by the actual encoded audio frame data. 2.4.3.1 Extended Type III Format Type Descriptor The first part of the Extended Type III Format Type descriptor is identical to the Simple Type III Format Type descriptor (See Section 2.3.3.1, “Type III Format Type Descriptor”.) Two additional fields are added to describe the Packet Header. The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”). Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 25 If the Packet Header is not used, then the bHeaderLength field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0. Table 2-8 Extended Type III Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 8 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant EXT_FORMAT_TYPE_III. Constant identifying the Format Type the AudioStreaming interface is using. 4 bSubslotSize 1 Number The number of bytes occupied by one audio subslot. Must be set to two. 5 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subslot. 6 bHeaderLength 1 Number Size of the Packet Header, in bytes. 7 bSideBandProtocol 1 Constant Constant, identifying the Side Band Protocol used for the Packet Header content. 2.4.4 Side Band Protocols This specification currently defines a single Side Band Protocol. Additional Protocols can be added later if needed. 2.4.4.1 Presentation Timestamp Side Band Protocol The Presentation Timestamp protocol only uses the Packet Header to convey high resolution time information over the isochronous pipe. The Packet header is 12 bytes in size. It must occur at the start of each VFP. Bit D0 in the bmFlags field indicates whether this is a valid timestamp (D0 = 0b1) or a repeated or non-valid timestamp (D0 = 0b0). When D0 is set to zero, the time fields of the Packet Header must be ignored. The qNanoSeconds field indicates the time T at which the first sample in the VFP needs to be rendered with respect to the start of the stream (T = 0). The qNanoSeconds field can range from 0 to 263-1 ns (Bit 63 is considered to be a sign bit and must be set to zero). It is up to the entity that generates the timestamp to decide to which accuracy the timestamp will be rendered. Table 2-9 Hi-Res Presentation TimeStamp Layout Offset Field Size Value Description 0 bmFlags 4 Bitmap D30..0 Reserved. Must be set to 0.D31 Valid. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集